i/1 


HD-A135  513  KERNEL  AND  SVSTEM  PROCEDURES  IN  FLEX<U)  ROYAL  SIGNALS 
AND  RADAR  ESTABLISHMENT  MALVERN  (ENGLAND) 

I  F  CURRIE  ET  AL  AUG  83  RSRE-MR-3626  DRIC-BR-89750 

F/G  9/2 


UNCLASSIFIED 


NL 


MEMORANDUM  No.  3626 

ROYAL  SIGNALS  &  RADAR 
ESTABLISHMENT 


KERNEL  AND  SYSTEM  PROCEDURES  IN  FLEX 

Author:  I  F  Currie,  J  M  Foster 
P  W  Edwards 


PROCUREMENT  EXECUTIVE, 

MINISTRY  OF  DEFENCE, 

RSRE  MALVERN, 

W0RCS*  aeuecte 

0£G  0  '( ^ 


<»>  t  a 

v  i 

/»»  W 


88  11 


UN!  i.v'Tcn 


hrwA  and  Syataai  procedures  in  Rw 


Contents 


1. 


5. 

5. 

7. 

9. 

9. 

0. 


Introduction 

Virtual  Machines  and  Processes 

File  stores 

Vdua 

Exceptions 

Loading  and  asseMbly  of  programs 
Marne  mad  value  identification 
Dictionary  utilities 
The  User  procedure 
Conclusion 


Index  and  dossar 


1.  Introduction 


Tho  Kernel  of  Flex  is  a  set  of  procedures  which  do  the  resource 
allocation  and  raw  peripheral  transfers  of  the  Flex  system.  Generally 
these  procedures  run  in  privileged  aode  (see  Flex  Firmware  Cl]);  in 
fact,  one  could  almost  define  Kernel  as  being  that  set  of  procedures 
which  run  in  privileged  mode. 

Some  of  the  procedures  in  Kernel  are  available  directly  to  the  general 
user;  these  fora  the  Kernel  interface.  To  the  user,  all  procedures  are 
treated  in  the  ume  manner,  so  he  should  find  no  difference  between  a 
Kernel  procedure  Mid  any  other.  In  common  with  all  Flex  procedures,  the 
pointer  which  is  a  Kernel  procedure  can  only  be  passed  around  and  called 
-  one  cannot  use  the  pointer  to  dig  into  Information  which  the  procedure 
uses.  To  this  extent  then,  the  Kernel  Interface  should  be  regarded  as  an 
extension  of  the  firmware  in  that  the  user  is  completely  free  to  use  any 
of  the  non-privileged  instructions  and  any  of  the  interface  procedures 
in  any  manner. 

The  exact  definition  of  a  what  is  meant  by  a  system  procedure  is  much 
less  dear.  The  procedures  which  I  call  System  procedures  are  all 
written  in  non-privileged  mode.  They  form  the  interface  between  the 
user  and  a  particular  operating  system  written  on  top  of  the  Kernel. 
This  operating  system  is  sometimes  called  Curt,  although  the  naie  should 
more  properly  be  applied  to  the  command  Interpreter  of  the  Flex 
operating  system  C2].  The  charaotertistlos  of  this  operating  system  are 
such  that  the  dividing  line  between  system  and  non-system  procedures  is 
largely  dependent  on  the  observer;  a  user  could  construct  a  new  system 
in  Flex  which  uses  as  much  or  as  little  of  the  current  system  as  he 
required  without  a  great  deal  of  trouble.  Thus,  the  choice  of  the 
particular  procedures  to  be  described  as  System  procedures  is  largely 
subjective.  Hy  usuel  criterion  is  to  ask  whether  I  can  give  a  program 
text  which  describes  it  completely,  tsking  other  Kernel  and  System 
procedures  as  being  defined.  If  the  Miswer  is  no,  then  the  procedure  is 
an  System  procedure.  This  usually  arises  from  the  fact  that  there  is 
some  non-textual  value  bound  into  the  procedure,  for  example  a 
dictionary  held  in  file-store. 

The  procedures  described  in  chapters  2-5  are  all  Kernel  procedures  with 
most  of  the  rest  being  simply  non-privileged  System  procedures.  They 
all  happen  to  have  been  written  in  Flex  Algol  68  and  so  the  descriptions 
of  the  interface  procedures  in  the  following  chspters  are  generally 
expressed  in  Algol  68.  However  this  does  not  imply  thet  they  cen  only 
be  called  from  Algol  68  programs  or  Indeed  thst  Flex  is  an  Algol  68 
machine.  The  underlying  structure  of  Flex  is  much  more  powerful  than 
any  hypothetical  Algol  68  "machine”.  The  total  relaxation  of  all  of  the 
Algol  68  scope  restrictions  in  the  Flex  compiler  is  one  indication  of 
this. 
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2.  Virtual  machines  and  Procaaaaa 
2.1  Gaoaral 

A  Virtual  Naohina  on  Flex  ia  initiated  by  the  reception  of  an  WHITE 
Control/A  fro*  a  vdu.  Thia  results  in  the  construction  of  procedures 
and  data  structures  particular  to  the  Virtual  Machine.  Each  Virtual 
Machine  gets  a  tine-slice,  sharing  the  total  tine  with  other  Machines  in 
a  round-robin.  Coaaunieatlon  between  Virtual  Machines  is  usually  done 
via  the  file-store. 

Eaoh  Virtual  Machine  has  a  set  of  processes  which  (given  that  they  are 
not  held  up  for  other  reasons)  will  be  run  in  s  local  round  robin  using 
process  tine-slices,  regarding  the  Virtual  Machine  tine-slices  as  though 
they  were  contiguous.  Any  process  whieh  does  not  conplete  its  process 
tin*-sllee  through  being  held  by  a  peripheral  transfer,  will  be  run  for 
a  tine  equal  to  its  unexpired  tine-slice  as  soon  as  the  transfer  is 
ccnpleted. 

The  set  of  processes  of  a  Virtual  Machine  initially  consists  of  : 

1.  The  noraal  control  process  ,  which  will  usually  be  the  one  which 
ruis  CUrt  and  noraal  progrms.  This  Is  the  principal  process  of 
the  Machine. 

2.  The  break-in  proeess  which  initially  is  in  a  loop  denanding  to 
read  the  BREAK  IM  LINE  on  the  vdu.  If  and  when  this  read  is 
oanpleted  by  sending  the  break-in  line,  process  1  will  be  failed. 

The  Kernel  interface  procedures  given  here  allow  one  to  create. 
Identify  and  synchronise  processes. 


2.2  PROC  nake_process  a  PROC  (PROC  VOID)VOID: 

Make_prooess  is  a  procedure  which  will  create  a  new  process  in  the 
Virtual  Machine.  A  call  of  aake_process  delivers  a  procedure  called 
the  interrupt  for  this  new  process.  In  order  to  run  a  PROC  VOID 
f  in  the  new  process,  one  oalls  the  soft_interrupt  with  f  ss  a 
par  meter.  A  subsequent  call  of  the  soft_lnterrupt  with  another  PROC 
VOID  g  will  result  in  a  FAIL(0,  g)  if  f  is  not  completed  in  the  new 
process;  otherwise  g  will  rin  in  the  new  process. 


2.3  PROC  own_si  a  (PROC  VOID  actlon)VOID: 

The  procedure  own_si  is  the  soft_lnterrupt  for  the  principel  process 
of  the  current  Virtual  Machine.  This  would  usually  be  used  to  fail 
this  process  froa  other  processes. 

2. A  PROC  breaksi  a  (PROC  VOID  breakln_actlon)VOID: 

The  procedure  break_sl  is  the  soft_interrupt  for  the  break-in 
prooess  of  the  Virtual  Machine.  The  initial  procedure  running  in  the 
break-in  prooess  Is  written  so  that  failures  are  trapped  and,  in 
particular,  the  FAIL(0,  g)  produced  by  break  si(g)  will  result  in  g 
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being  called  frea  within  the  break_in  process.  This  asy  be  used  to 
allow  the  user  to  create  his  own  break-in  action. 

2.5  PROC  asks  saaa  ■  (IMT  n)SEMA: 

Where  SEMA  «  PHOCCBOODVOID; 

The  value  of  the  parsaeter.  n,  of  a  call  of  aake_seaa  is  the  Initial 
value  of  a  new  seaaphore  given  by  the  answer- to  the  call.  The 
operation  of  downing  (seouring)  the  seaaphore  is  perforaed  by  applying 
a  FALSE  par»eter  to  the  SEMA;  raising  (releasing)  the  seaaphore  by 
applying  a  TRUE  paraaeter.  The  usual  definition  of  a  seaaphore 
applies;  the  value  of  a  seaaphore  is  non-negative  and  any  process  irtiich 
tries  to  down  a  zero  seaaphore  is  suspended  until  the  seaaphore  is 
non-zero. 

2.6  PROC  tlaedjvait  «  (IMT  secs) VOID: 

The  call.  tiaed_wait( s)  holds  up  the  action  of  current  process  for  at 
least  s  seconds,  running  thereafter  when  there  are  no  other  runnable 
processes. 

2.7  PROC  own_tlae  *  LONG  INT: 

The  value  delivered  by  own_tiae  is  the  tiae  in  ailli-seconds  that  the 
current  process  has  been  running.  (The  tiae  of  day  is  given  by  an 
Instruction,  opcode  35). 

2.8  VECTOR C3CHAR  date 

The  current  date  given  in  the  fora  day/aonth/year  eg.  10/1/83 


3.  File  stores 


3.1  General 

Usually  the  user  will  only  be  aware  of  one  file-store  .entirely 
resident  on  disc.  His  knowledge  is  defined  entirely  by  the  disc  kernel 
procedures  and  disc  pointers  that  he  possesses.  These  disc  procedures 
are  arranged  so  that  (except  in  one  carefully  controlled  case)  no 
overwriting  of  data  occurs  -  one  oan  only  read  data  from  an  existing 
disc  pointer  or  write  a  chunk  of  data  to  create  a  new  block  on  disc 
pointed  at  by  a  new  disc  pointer. 

As  explained  in  (1],  the  aain  msmory  representation  of  a  disc  pointer 
is  a  locked  pointer  to  a  4-word  block.  The  key  for  unlocking  this 
pointer  is  the  sane  for  all  pointers  belonging  to  the  same  file-store. 
Disc  pointers  can  also  exist  in  their  own  file-store  where  their 
representation  is  4  bytes.  The  mediation  between  the  two 
representations  is  done  by  the  disc  reading  procedures  in  such  a  way  so 
that  if  a  disc  pointer  to  a  file-store  block  is  read  in  two  different 
places  the  main  memory  representation  will  be  the  same  locked  pointer  in 
both  cases.  This  implies  that  it  is  relatively  easy  to  alias  file-store 
blocks  with  main  memory  blocks  to  facilitate  sharing  of  common  blocks. 
The  correspondences  and  alias  information  are  tied  together  with  shaky 
pointers  so  that  the  memory  does  not  become  clogged  up  with  disc 
pointers  and  their  aliases. 

The  only  exception  to  the  no  overwriting  rule  is  the  use  of  disc 
references.  A  disc  reference  is  essentially  a  variable  on  disc  which 
can  contain  a  disc  pointer.  This  variable  can  be  read  using  d_to_b 
and  can  be  assigned  to  (with  caveats)  using  to_dr .  ”  ~ 

Since  most  writing  to  the  disc  will  increase  the  size  of  the  filestore, 
the  filestore  is  periodically  garbage-collected.  This  is  done  by  an 
off-line  program  and,  except  for  the  fact  that  the  filestore  is 
inaccessible  during  garbage-collection,  the  user  is  usually  unaware  of 
its  action,  except  for  its  influence  on  shaky  pointers  as 
described  in  3.5. 

In  the  following  procedures  a  DISCPTR  or  DISCREF  is  formally  an  Algol 
68  I  NT,  aince  no  Algol  68  mode  oonstruotor  can  adequately  describe  a 
disc  pointer. 


3.2  Pi so  writers 


3.2.1  PROC  npb  to  d  *  (VECTOR [ ]XTTPE  data)  DISCPTR: 
where  frY?E  is  FLAT 

or  VECTOR []FLAT, 

Where  FLAT  is  XNT,  REAL,  CHAR  .... 

or  STRUCT(FLAT . ), 

or  UNION  (FLAT . ). 

This  procedure  writes  data  to  a  block  on  disc  delivering  a  disc 
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pointer  to  that  block  where  data  contains  no  pointers.  The  node  of  the 
parameter  allows  one  to  gather  together  data  of  diverse  non-pointer 

■odes. 

3.2.2  PROC  pb_to_d  *  (VECTOR  []  XT  YPE  data)  DISCPTR: 

This  procedure  writes  data  to  a  block  on  disc  delivering  a  disc 
pointer  to  that  block  where  data  aay  contain  disc  pointers.  Once  again 
the  data  written  is  gathered  together;  this  tine  however  each  item 
written  aust  be  aultiples  of  words. 

3.2.3  PROC  o_to  d  *  (INT  ws.REF  VECTOR t)IMT  consts. 

REF  VECTOR []CHAR  code, BOOL  proc)DISCFTR: 

This  procedure  oreates  a  code-block  on  disc,  where  ws  is  the 
work-space  size  required  by  the  code.  The  constants  of  the  code_block, 
which  aay  contain  other  disc  pointers  are  given  in  consts.  A  code_block 
disc  pointer  is  delivered  if  proc  is  FALSE;  otherwise  a  disc  pointer  to 
a  procedure  with  no  non-locals  is  delivered. 


3.2.4  PROC  p_to_d  s  (DISCPTR  eb .VECTOR [JXTYPE  nls)DISCPTR: 

This  procedure  oreates  a  procedure  on  disc  .with  code-block  given  by 
the  oode-bloek  disc  pointer  eb  (produced  by  e_to_d)  and  non_locals 
given  by  nls  (aay  contain  disc  pointers  and  auatTWin  word  aultiples). 
A  disc  pointer  to  the  praoodnre  is  delivered. 


3*3  Pino  renders 

3.3.1  PROC  d  to  b  •  (DZaCTTR  d)PT»: 

"  ’  Rhere  ft*  •  JM T; 


This  preeedwre  reads  the  dine  bleak  oecraopendln§  to  disc  pointer  d, 
into  e  ado  aeeery  bleak  end  c  pointer  to  this  block  is  delivered  as 
answer.  The  type  of  eels  east  bleak  produced  depends  on  the  type  of 
the  dine  pointer  d  which  in  tvM  depends  on  how  it  was  produced. 

Thus: 

if  d  had  been  produced  by  apb  te  d  the  bleak  type  is  3  (non-pointer) ; 
if  d  had  been  prod  wood  by  pb_to_l  the  block  type  is  t  (nomal) ; 
if  d  had  been  prod  weed  by  e_te_Jj  the  black  type  is  2  (code-block) ; 

if  d  had  bean  produced  by  p”te~d  the  block  type  is  $  (closure); 

if  d  is  a  dice  reference  then  answer  is  the  contents  of  the  disc 
reference,  which  is  uouolly  a  disc  pointer  (type  6  block). 

Zb  all  oases  the  pointer  delivered  is  such  that  the  contents  of  the 
bloek  cannot  be  altered  l.e.  in  the  first  three  cases  above  (types  2, 

3  and  4)  the  pointer  is  looked.  This  Beans  that  this  saae  block  can  be 

given  as  an  answer  to  any  eall  of  d_toJb  with  the  sane  parameter  and 
this  block  oan  be  shared  between  aany  users  and  prograas.  Since  all 
oodejbloeks  are  read  into  aeaory  using  d_to_b ,  the  saving  in  both  disc 
access  and  aaln  aeaory  usage  is  quite  significant. 
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3.3.2  PROC  from  disc  *  (DISCPTR  d .VECTOR []REF  XTYPE  start) REF  YTYPE: 

Wherr  REF  TTTPE  can  be  coarcad  to  {REF}  FLAT, 

or  to  {REF}  VECTOR []FLAT. 

This  procadura  raads  the  data  tram  the  block  pointed  at  by  d.  This 
disc  pointer  oust  have  been  produced  by  some  call  of  npb_to_d  or 
pb_to_d  and  the  data  read  la  identical  to  that  given  by  the  parameter 
of“ this  oall.  The  data  is  assigned  to  the  variables  given  by  the 
parameter,  start,  in  order  starting  from  the  beginning  of  the  data  and 
any  regaining  data  is  delivered  as  the  answer.  Usually  from_disc  will 
be  called  in  suoh  a  context  so  that  this  remainder  (of  mode  "REF  YTPE) 
will  be  coerced  to  some  vector.  Clearly,  if  disc  pointers  are  being 
read  into  start,  then  the  corresponding  variables  in  start  must  occur 
In  multiples  of  words. 

The  procedure  from_ disc  oan  be  used  ss  an  effective  inverse  to 
either  npb_to_d  or  pb_to_d,  providing  a  scatter-gather  pair. 


3.4  Disc  reference  procedures 
Oise  references  cm  be  read  using  d_to_b  (3.3.1). 


3.4.1  PROC  to_dr  *  (DISCREF  dr, HIT  old .new) VOID: 

This  procedure  assigns  new  (usually  a  disc  pointer)  to  the  disc 
reference  dr,  provided  that  the  old  value  contained  in  dr  was  old 
(Integer  or  disc  pointer) •  If  the  old  value  was  not  old  then  the 
procedure  falls.  Since  to_dr  acts  on  the  file  store  as  an  elementary 
operation,  this  check  allows  a  fairly  simple  method  of  resolving 
difficulties  caused  by  simultaneous  altering  of  dictionaries  pointed 
at  by  disc  references. 


3.4.2  PROC  new_dr  *  DISCREF: 

This  procedure  creates  a  new  disc  reference  (containing  integer  0) 
and  delivers  it  as  an  answer.  This  procedure  is  hidden  from  most  users 
but  is  included  here  for  completness. 


3.5  Shaky  disc  pointers 

Disc  pointers  produced  by  npb_to_d  or  pb_to_d  can  exist  in  a  "shaky" 
form.  That  is  to  say,  so  long  as  a  normal  or  "firm"  version  of  a 
pointer  exists  somewhere  in  the  filestore  then  this  firm  version  can 
always  be  recovered  tram  a  shaky  version  of  the  pointer  by  appllestion 
of  the  procedure  flrm_dptr  below.  If  there  is  s  shaky  disc  pointer 
with  no  corresponding-  firm  version  in  the  filestore  then  the  shaky 
pointer  will  be  replaced  by  0  (and  any  associated  space  recovered)  when 
the  filestore  is  garbage-collected . 
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3.5. 1  PBOC  fimjdptr  *  (DISCPTR  shaky)  DISCPTR: 

This  procedure  delivers  the  firs  version  of  its  shaky  disc  pointer 

parameter . 

3.5.2  PBOC  shake_dptr  «  (DISCPTR  ptr)  DISCPTR: 

Ibis  procedure  delivers  the  shaky  version  of  the  paraneter  ptr  which 
ims  produced  by  npb  to  d  or  pb  to  d. 


4.  Vdua 


4.1  General 

When  WHITE  Control/A  is  typed  on  a  vdu.  Kernel  creates  a  specific  vdu 
procedure  to  go  with  the  Virtual  Machine  (see  2.1).  This  procedure  is 
now  the  only  one  capable  of  communicating  with  the  particular  vdu  and 
will  remain  valid  wtil  WHITE  Control/A  is  typed  again  on  that  vdu. Thus 
a  Virtual  Machine  usually  has  sole  possesion  of  a  physical  vdu  simply  by 
being  the  only  one  which  has  the  correct  vdu  procedure. 

The  Logics  vdus  have  the  capacity  to  display  characters  in  various 
forms  eg  reversed  video,  flashing,  underlined  etc.  An  underlined 
character  is  indicated  by  adding  128  to  the  0  -  127  ISO  representation 
of  the  character  sent  to  the  vdu.  Other  forms  are  indicated  by  the 
parameters  of  the  procedure  vdu. 

Each  call  of  the  vdu  procedure  is  a  single  interaction  consisting  of 
writing  some  lines  (possibly  empty)  to  an  area  of  the  screen  and  then, 
optionally,  waiting  for  a  control  key  to  be  pressed  to  indicate  that  the 
lines  on  some  area  of  the  screen  are  to  be  delivered  as  the  answer  to 
the  procedure.  Several  interactions  may  be  in  progress  simultaneously  to 
the  same  vdu  arising  from  calls  of  the  vdu  procedure  in  different 
processes.  The  NEXTREAD  sequence  on  the  vdu  keyboard  will  cycle  the 
cursor  through  the  various  read  areas  to  allow  any  of  the  extant 
interactions  to  be  completed.  The  most  obvious  example  of  this  is  the 
break-in  process,  which  is  usually  held  up  waiting  for  the  top  line  of 
the  screen  to  be  sent. 

4.2  PROC  vdu  *  (VECTOR HINT  pre, VECTOR []TEXT  mess, VECTOR []INT  post, 

VECTOR []REF  INT  an s) REF  VECTOR[]LINE: 

Where  TEXT  s  UNION  (REF  VECTOR  t]LINE.  VECTOR  [  KHAR, 

VECTOR  [  JVECTOR  [  KHAR  ) , 
and  LINE  *  REF  VECTORUCHAR; 

This  procedure  sends  the  lines  defined  by  mess  to  an  area  of  the  screen 
called  the  write  area  which  is  defined  by  the  vector  pre.  Each  element 
of  the  vector  mess  starts  on  a  new  line.  If  a  component  of  mess  is  a 
REF  VECTOR  []  LINE  then  each  of  its  elements  will  start  on  a  new  line. 
The  components  of  a  VECTOR  []  VECTOR  []  CHAR  are  concatenated  to  form 
one  line. 

If  post  is  an  empty  vector,  then  this  is  a  write-only  interaction  and 
NIL  is  delivered  as  the  answer.  Otherwise  post  defines  a  read  area  on 
the  screen  the  lines  of  which  will  be  delivered  as  the  answer  to  vdu 
when  the  Interaction  is  completed  by  keyboard  action.  The  variables  in 
ans  will  then  show  how  the  the  interaction  was  completed. 

The  vector  pre  must  have  upper  bovnd  7,  and  the  significance  of  each  of 
its  elements  is  as  follows: 
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pre£l]  :  any  or  all  of  these  bits  aay  be  present  :- 

2  -  Lines  after  the  last  written  will  not  be  cleared . 

4  -  Hie  cursor  will  not  be  shown  for  the  read  unless  it  is 
invoked  by  next_read  on  the  vdu 
8  -  There  will  be  a  left  aargin  during  the  read  part  of 
the  exchange  into  which  the  cursor  trill  not  aove.  Only 
the  characters  to  the  right  of  this  will  be  returned. 

The  position  is  set  by  post[4] 

16-  The  area  will  be  read  without  interacting  with  the  user. 

pre[2]  :  The  line  width  in  characters  £  1  :  160  ]. 

pre£3]  :  Absolute  line  nuaber  of  first  lin.  of  write  area  where  the 
top  line  of  the  screen  is  0,  the  bottom  one  23. 

pre[4]  :  Number  of  lines  of  required  width  in  write  area. 

pre£5]  :  Relative  line  nunber  (0  is  the  first  line)  within  current 
write  area  onto  which  the  first  LINE  will  be  written.  Unless 
2  is  present  in  pretl]  the  remaining  lines  in  the  area  will 
be  cleared.  pre£5]  aay  lie  between  -23  and  46.  If  it  is 
outside  the  write  area  the  data  in  the  write  area  will  be 
scrolled  up  or  down  so  that  the  first  line  is  just  inside  the 
area.  If  enough  lines  are  written  to  go  past  the  bottom  of 
the  area  the  data  in  the  write  area  will  be  scrolled  up. 

pre[6]  :  Character  position  £0  :  pre£2]-1]  in  line  from  which  writing 
will  start. 

pre£7]  :  "Colour"  used.  Any  or  all  of  the  following  bits  aay  be 
present  :- 

1  -  Blink 

2  -  Reverse  video 
4  -  Half  intensity 
16-  Invisible 

The  vector  post  aust  have  upper  bound  0  or  5,  and  in  the  latter  case, 
the  significance  of  each  of  its  elements  is  as  follows: 


post£ 1 ] 
post  [2] 
post£3] 

post£4] 

post  £53 


Absolute  line  number  of  first  line  of  read  area  £  0  :  23  ]. 

Number  of  lines  of  required  width  in  read  area. 

Relative  line  number  £0  :  post£2]-1]  within  read  area  for 
initial  position  of  cursor. 

Character  position  £0  :  pre£2]-1]  for  initial  position  of 
cursor. 

"Colour"  to  be  used  for  read  area.  As  for  write. 


The  vector  ans  aust  have  upper  bound  <*  4  ,  and  the  significance 
of  each  eleaent,  provided  it  exists  and  is  not  NIL,  is  as  follows: 


ans[1]  :  A  codification  of  the  keystroke(a)  which  sent  the  read  data 

152  -  DU PL 

153  -  DEL  LINE 
148  -  INS  LAST 
150  -  INS  LINE 
145  -  up  arrow 

147  -  south  west  arrow 
139  -  down  arrow 

176  -  VOID 

177  -  GO  IN 
179  -  RESULT 
181  -  DO 

<128  -  given  by  WHITE/x  and  ansCl]  Is  ascii  code  for  x 

ans[2]  :  Multiplier  number;  will  be  1  unless  the  *10  key  has  been 
used  immediatly  before  the  sending  keystroke(s) ,  in  which 
case  it  will  be  a  multiple  of  10  <  230  minus  the  number  of 
times  the  operation  was  performed  on  the  screen  before 
needing  to  send  lines.  If  it  is  >230  then  the  *MAX  key  was 
pressed . 

ans£3]  :  Relative  line  number  [0:  post[2]-1]  of  final  position  of 
cursor. 

ans[4]  :  Character  number  [0:  pre[2]-1]  of  final  position  of  cursor 

The  lines  returned  depend  on  the  key  which  was  pressed  to  send  the  data 
back. 

Let  q  »  mln(post[2],  ans[2]) 

r  s  min(post[2]  -  ans[3],  ans[2]) 

VOID,  GO  IN,  RESULT,  DO  send  back  the  whole  read  area. 

Up  arrow  sends  back  the  bottom  q  lines. 

Down  arrow  and  south  west  arrow  send  back  the  top  q  lines. 

INS  LAST  sends  back  the  bottom  r  lines. 

DEL  LINE  and  DU PL  send  back  r  lines  starting  from  line  ans[3] 

INS  LINE  sends  back  the  bottom  r  lines  if  ans[4]s0,  the  bottom 
postC2]>ansC3]  lines  if  ans[4]/«0. 

WHITE/x  sends  back  no  lines. 

The  definition  of  the  lines  which  are  returned  may  appear  complicated; 
however,  it  can  be  summarised  by  saying  that  the  minimum  number  of  lines 
are  sent,  compatible  with  the  implementation  of  the  nominal  action  of 
key  pressed. 
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5.  Exceptions 


As  described  in  the  Flex  Firmware  [1],  a  exception  in  D-state  provokes 
the  call  of  an  otherwise  inaccessible  Kernel  procedure,  failure,  to 
reoord  and  pass  on  information  about  the  exception.  The  failure 
procedure  is  called  in  place  of  the  procedure  call  which  contained  the 
Instruction  which  raised  the  exception  and  it  generates  a  structure  of 
■ode  F  where: 


1$ 


NODE  F  s  STRUCT (PTR  locals, INT  pc.sf,  PTR  code_block,  EP  ep) 
where  the  fields  are: 

locals  is  a  pointer  to  the  workspace  in  which  the  exception  occurred. 

pc  is  byte  displaceaent  from  the  start  of  code  of  the  instruction  in 
eode_block  which  was  in  error. 

at  is  byte  displacement  from  the  start  of  locals  of  the  stack  front 
when  the  exception  occurred . 

eodc_block  is  a  pointer  to  the  code  block  in  which  the  exception 
occurred . 

ep  is  the  error  pair  corresponding  to  the  error. 

Since  failure  does  a  Exit-fail  Instruction  (Op  code  69)  with  a  ref  to 
this  structure  in  U,  the  mode  EP  could  be  REF  F.  The  net  effect  is  that 
a  chain  of  mode  REF  F  is  formed  by  successive  failures  through  various 
procedures  until  an  instruction  is  encountered  which  can  cope  with  the 
Illegal  value  produced.  This  is  usually  the  unite-illegal  instruction 
(opcode  165)  which  allows  one  to  access  the  characteristic  word  pair  of 
the  illegality  (in  this  case  the  REF  F)  .  This  chain  may  then  be 
analysed  by  procedures  such  as  diagnose  to  indicate  error  positions  in 
the  code  an<*  the  values  of  locals  in  the  chain  of  failing  procedure 
workspaces. 
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6.  Loading  and  aaaaabllng  program 

Coapilars  for  Flax  usa  tha  primitive  disc  writing  procedures  to 
create  filestore  codeblocks  and  procedures.  Thus,  most  of  the 
code-blocks  used  in  Flex  are  formed  by  creating  a  disc  code-block  using 
c_to_d .  Of  course .  the  code  can  only  be  obeyed  when  this  code-block  is 
loaded  from  disc  into  aain  aeaory.  This  usually  takes  place  when  a 
procedure  aade  fraa  this  code-block  is  called  -  an  interrupt  occurs  in 
the  aiddle  of  the  calling  sequence  and  the  interrupt  procedure  then 
called  will  replace  the  disc  code-block  pointer  with  a  aain  memory 
pointer  using  d_to_b  (see  [1]).  This  is  entirely  invisible  to  the  user 
and  hence  the  distinction  between  disc  and  main  store  code-blocks  tends 
to  be  rather  acadasio. 

The  basic  unit  of  prograaaing  in  Flex  is  the  procedure  and  a  Flex 
coapiler  produces  a  filestore  procedure  corresponding  to  the  source  text 
as  a  part  of  its  result.  This  procedure  is  one  which  will  deliver  the 
Interface  values  defined  in  the  source  text  as  its  result,  eg  those 
values  corresponding  to  the  KEEPlist  in  an  Algol68  module  or  the 
"specification"  part  of  an  Ada  compilation  unit.  In  the  course  of 
evaluating  the  procedure,  a  value  from  another  module  or  compilation 
unit  USEd  by  the  former  is  derived  simply  by  calling  its  corresponding 
procedure.  Thus  the  filestore  procedure  corresponding  to  a  program  text 
contains  (usually  in  its  non-locals)  means  of  deriving  the  filestore 
procedure  corresponding  to  each  of  the  external  modules  used  by  that 
program  text.  Usually,  the  external  filestore  procedure  is  not  itself 
in  the  non-locals,  but  rather  a  kind  of  a  reference  to  the  procedure 
called  a  Module. 

The  reason  for  a  Module  to  be  a  reference  to  the  procedure  rather  than 
the  procedure  itself  lies  in  the  requirement  that  one  should  be  able  to 
recompile  and  reconstruct  program  units  without  invalidating  other  units 
which  use  them.  This  implies  some  degree  of  assignability.  The  details 
of  whether  or  not  one  can  change  a  Module  belongs  more  properly  to  a 
description  of  the  language  and  compiler;  however  the  kernel  of  Flex 
does  define  a  language  independent  mechanism  for  the  construction  of 
programs  in  this  modular  fashion  such  that  one  can  ensure  their 
consistency  at  least  at  the  modal  level. 

6. 1  Modules 

A  Module  in  Flex  is  a  three  word  object: 

MODE  MODULE  «  STRUCT(  DEREF  deref .ASSIGN  assign,  SPEC  spec) 


This  structure  effectively  defines  a  variable  (existing  in  filestore) 
containing  four  words.  The  space  for  these  four  words  form  part  of  the 
user  environment  (see  8.1  and  9.).  The  deref  and  assign  fields  of  this 
structure  allow  one  to  access  and  change  these  four  words,  subject  to 
certain  constraints.  The  field,  spec,  is  a  pointer  to  filestore  disc 
block  produced  by  some  call  of  npb_to_d;  when  used  by  a  compiler  this 
will  generally  be  some  translatlon~of  the  interface  specification  of  a 
compiled  module. 

The  deref  field  is  a  disc-pointer  to  a  procedure  of  mode  PROC  DATA 
and  where  DATA  has  been  produced  by  the  compiling  system  : 


NODE  DATA  «  STRUCK  PROG  prog, 

SPEC  shaky_spec, 

EDFILE  text, 

WORD  spare) 

Here  the  shaky_spec  field  is  a  shaky  version  of  a  disc-pointer  to  an 
Interface  specification  as  above.  Its  shaky  properties  allow  one  to 
recover  the  space  occupied  by  DATA  when  the  MODULE  is  no  longer 
referred  to. 

The  assign  field  of  a  MODULE  is  another  disc-pointer,  this  time  to  a 
PR OC (DATA,  BOODVOID.  Letting  these  two  procedures  be  deref  and  assign 
respectively,  the  call  assign  (d,  b)  will  alter  the  DATA  referred  to  by 
the  MODULE  to  d  if  b  is  TRUE  (as  in  the  function  change_spec) .  If  b  is 
FALSE  and  the  interface  specifications  given  by  specOFd  and  shaky_spec 
OF  deref  are  the  sane,  then  the  prog,  text  and  spare  fields  the  MODULE 
are  changed  to  that  of  d  (as  in  the  function  aaend).  The  comparison  of 
the  specs  is  done  by  reading  the  non-pointer  blocks  given  by  the  specs 
and  canparing  them  character  by  character.  If  b  is  FALSE  and  the  specs 
are  not  the  sane  then  the  call  fails. 

6.1.1  PROC  new  *  (PROG  prog .SPEC  spec .EDFILE  text)MODULE: 

This  procedure  creates  and  initialises  a  new  MODULE  in  the  current 

environment.  The  initial  DATA  in  the  MODULE  is: 

(prog.  shake_dptr(spec) ,  text,  0) 

The  three  words  which  form  the  parameters  of  new  are  usually  the 

result  of  a  compiler  e.g.  the  procedure  algol68. 

6.2  Assembling  program 

Most  progam  loading  in  Flex  is  done  implicitly  in  the  interpretation 
of  Curt  commands;  what  follows  here  is  a  description  of  the  primitives 
Involved . 

In  order  to  load  the  program  corresponding  to  a  MODULE,  one  applies 
a  procedure  of  mode  LOADER  to  it  where: 

MODE  LOADER  =  PROC ( MODULE )KEE PS 

where  KEEPS  is  a  (mainstore)  pointer  to  a  block  containing  the  set  of 
interface  values  of  the  program.  The  internal  structure  of  this  block 
is  deducible  from  the  spec  field  of  the  module;  its  details  depend  on 
the  compiler  and  language.  A  call  of  a  loader,  say  load(m),  will  fail 
in  a  characteristic  manner  if  specCFm  and  specOFd erefOFm  are  unequal; 
one  cannot  load  programs  which  contain  inconsistent  use  of  modules. 

The  actual  loader  used  depends  on  context;  the  user  can  write  his  own. 
The  action  of  a  loader  is  usually  fairly  trivial,  since  the  prog  field 
of  the  DATA  is  itself  a  disc  procedure  produced  by  the  compiler  which 
evaluates  its  own  KEEPS  and  loads  any  modules  used  by  it.  In  order  to 
do  this,  it  requires  to  call  the  loader  recursively  on  any  internal 
module,  and  so  the  procedure  in  the  prog  field  has  a  loader  as  a 
parameter  i.e.  the  mode  PROG  is  a  disc-pointer  to: 

PR0C(L0ADER , INT )KEEPS 

The  Integer  parameter  is  currently  not  used  by  the  compilers  on  Flex. 
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6.2.1  PROC  get_module  =  (MODULE  n,  LOADER  1,INT  c) KEEPS 

Not  all  program  defined  by  nodules  lives  in  filestore;  nost  of  the 
procedires  in  the  kernel,  for  example,  can  only  exist  in  nain  neaory 
in  a  transitory  fashion.  These  nodules  are  recognised  by  this 
procedure,  which  gives  the  required  KEEPS  to  these  "in-store"  nodules 
as  well  as  doing  the  standard  operations  as  described  above  to  nornal 
nodules.  Thus,  if  n  is  a  standard  nodule  then  the  answer  is  the 
answer  to  a  call  of  the  procedure  derived  fron  the  prog  field  of  a 
with  1  and  c  as  parameters;  otherwise,  the  KEEPS  corresponding  to  this 
nodule  is  already  bound  to  the  procedure  and  this  is  the  answer  to 
get_aodule.  A  non-standard  nodule  is  recognised  by  its  deref  and 
assign  fields,  both  being  scalars  rather  than  disc-pointers. 

The  kernel  and  systen  procedures  defined  in  this  paper  are  nostly 
accessible  in  program  using  the  nodule  nanes  (defined  in  the  ooaaon 
dictionary)  fomed  by  using  the  jn  suffix  on  the  procedure  nane  e.g. 
vdu_n,  fron_disc_n  etc. 

A  loader  is  usually  constructed  by  using  the  standard,  procedure 
nake_loader : 

PROC  make_loader  *  (  PROC  (MODULE,  LOADER.  INDKEEPS  g_n,  INT  c  )  LOADER 

The  answer  to  a  call  of  nake__loader  is  a  loader  which  calls  g_ja 
exactly  once  for  each  different "nodule  found  in  the  tree  of  evaluation 
of  the  program  being  loaded;  the  loader  supplied  as  a  parameter  to  gjn 
is  this  loader  Itself.  If  the  same  nodule  is  encountered  nore  than 
once  then  the  KEEPS  which  was  the  result  of  the  first  evaluation  is 
used  for  subsequent  ones.  This  neans  that  the  sane  set  of  values  are 
bound  to  the  program,  regardless  of  how  nany  tines  the  nodule  was 
used. 

The  reason  for  this  apparent  complication  in  loading  and  assenbling  is 
that  the  neaning  of  a  particular  nodule  nay  depend  on  the  context  of 
use.  As  a  trivial  exmiple,  the  nodule  vdu_n  nust  give  different 
values  for  each  Virtual  Machine.  A  less  trivial  exaaple  occurs  where 
one  enters  a  new  naning  regine;  the  procedure  find  (which  gives  a 
value  corresponding  to  an  identifier,  see  7.2)  contained  in  the  nodule 
findjn  nust  allow  one  to  enter  (and  leave)  new  scopes.  The  general 
method  for  doing  this  is  to  re-deflne  get_module  in  an  inner  scope, 
usually  via  the  command  interpreter.  Curt.  The  new  get_nodule  would 
Intercept  sone  nodules,  delivering  already  evaluated  KEEPS  in  these 
cases  and  call  the  old  get_nodule  for  the  other  cases.  Notice  that 
the  nodule  get_nodule_n~alnost  certainly  would  be  one  of  the 
Intercepted  nodules,  delivering  the  new  get_nodule  in  its  KEEPS,  so 
that  a  further  inner  redefinition  will  include  the  outer  one. 


6.2.2  PROC  eurrent_loader  *  (MODULE  a)KEEFS 

Ibis  procedure  is  the  loader  which  was  used  to  load  the  currently 
running  progrn.  A  call  of  this  procedure  froa  within  this  program 
will  load  the  requested  aodule  none  ally  if  it  is  not  already  part  of 
the  prograa;  if  it  is,  then  the  interface  values  already  bound  into 
the  prograi  are  delivered. 
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•  and  value  identification 


Moat  name  and  value  oorrtapondancaa  aade  in  Flex  are  dona  at  tha  laval 
of  tha  CUrt  interpreter  or  within  compiler*.  Tha  following  prooaduraa 
ara  thoae  primitives  used  to  do  it. 

Tha  aaaning  of  a  naaa  in  Flax  ia  dependant  on  tha  context  or 
envlronaent  of  uae.  Thera  ara  two  different  waya  of  naing  an  object  - 
first,  where  tha  naaa  la  only  valid  for  tha  currant  session  (teaporary) 
and  secondly  where  tha  aaaning  of  tha  naaa  parslats  froa  session  to 
session.  Any  value  created  in  Flax  can  be  naaad  in  tha  first  way; 
however  tha  second  way  can  only  bo  dona  for  filestore  objects.  A 
filestore  object  la  essentially  one  which  oontalna  no  aain-atore 
pointers  -  it  can  of  course  contain  disc-pointers. 

Host  users  of  Flex  have  access  to  two  dictionaries  which  gives  the 
file-store  n  as  e-value  relationships;  one  which  is  private  to  the  user 
which  he  can  update  and  the  other  which  is  held  in  common  across  the 
systaa  which  he  cannot  update.  Both  of  these  of  these  are  obviously 
held  in  file-store.  The  teaporary  dictionary  la  held  entirely  in 
aaln-store  and  no  naae  clashes  are  permitted  between  this  and  the 
private  file-store  dictionary.  Thus  the  teaporary  dictionary  can  be 
regarded  as  a  main-store  extension  of  the  private  file-store  dictionary. 
Any  naae  clashes  between  the  private  and  coaaon  dictionaries  are 
resolved  by  giving  precedence  to  the  foraer . 


7.1  PROC  baslc_flnd  =  (VECTOR []CHAR  naae) REF  VECTOR []U VALUE 

where  UVALUE  *  UNION  (REF  VECTOR  HINT, 

REF  VECTOR [jSTRUCTdNT  fn)  . 

REF  VECTOR [ KHAR. 

REF  VECTOR []BOOL  ) 

This  procedure  delivers  the  set  of  values  of  mode  UVALUE  associated 
with  the  naae  in  the  current  environment.  Each  of  these  values  can  be 
vectors  of  Integers,  characters  or  bool e an s.  The  remaining  eleaent  of 
the  union  is  somewhat  historleal  and  is  intended  to  differentiate  those 
values  which  are  in  faot  disc  procedures.  The  first  value  of  the 
result  vector  is  the  principal  value.  There  need  not  be  any  others, 
but  if  they  are  given  the  second  is  the  Curt  aode  of  the  principal 
value,  the  third  a  LONG  INT  representation  of  the  date  and  tine  the 
naae  was  declared  and  the  fourth  an  editable  file  tdiich  oontalns 
information  on  the  value;  this  last  is  the  file  accessed  by  the 
function  info.  Thus,  given  that  d_to_b_js  is  a  naae  in  the  coaaon 
dictionary,  the  call  basic_find ( "d_to~b  a")  would  deliver  a  vector  of 
four  UVALUEs,  each  of  which  is  formally  a  vector  of  Integers.  The 
first  vector  would  have  three  elaxents,  since  d_to_b_m  is  actually  a 
NODULE  and  the  use  of  soae  suitable  unpack  operator~(  opcode  167)  on  the 
integer  vector  oould  produce  this  NODULE.  The  second  vector  has  one 
elanent  which  happens  to  be  a  dlso  pointer,  the  vector  itself  being  a 
representation  of  the  CUrt  aode  for  Nodule.  The  third  vector  has  two 
elements  giving  the  date  and  tlae  while  the  fourth  has  one  which  is  an 
editable  file  containing  roughly  the  same  text  as  given  in  3.3.1. 

The  aost  ooaaon  use  of  baslo_flnd  is  in  the  oonstruotion  of  new  find 
prooedures  as  below  using  the  aake_flnd  procedure.  The  procedure 
aake_flnd  takes  a  user's  basio_find  as  paraaeter  and  delivers  a  new 
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find  procedure.  Baking  sura  that  this  will  bind  the  new  find, 
bssio  find  and  getjnodule  into  any  calls  of  new  environoents  using  this 
new  find  as  well  as  any  new  naie  associations  required  by  the  user. 

7.2  PXOC  find  •  (VECTOR [ ]CHAR  n)VM: 

Where  VH  *  STRUCT  (REF  VECTOR  []INT  value  .node) 

A  call  of  this  prooedure  find  gives  the  value  and  Curt  node 
correspond ing  to  the  string  n  in  the  current  environment.  If  n  is  not 
defined  in  this  environment  then  the  call  fails. 

Although  the  foraal  Algol68  node  of  the  value  is  a  vector  of  integers, 
the  actual  value  could  equally  well  be  a  vector  of  characters  or 
booleans.  Thus,  a  suitable  aanifestation  of  the  unpack  operator 
(opcode  167)  could  transfora  this  value  to  any  Algol68  value  consisting 
of  a  number  of  words,  characters  or  booleans.  Siailarly,  the  use  of 
the  pack  operator  (opcode  166)  can  produce  the  vector  of  integers  from 
any  Algol68  value. 

Ibe  representation  of  the  Curt  node  corresponding  to  the  name  is 
defined  system-wide.  Thus,  if  the  nane  had  corresponded  to  an  editable 
file  then  the  CUrt  aode  would  have  been  Edfile  and  its  representation 
is  that  given  by  the  call  make-mode( "Edfile" ) . 

The  find  procedure  that  is  bound  to  a  program  is  usually  the  same  as 
that  used  as  a  paraaeter  to  the  current  call  of  the  command  interpreter 
curt  (see  9.1). 


7.3  PROC  keep  *  (INT  dec_type, VECTOR []CHAR  n.VM  v)VOID: 

A  call  of  keep  adds  (or  redefines)  the  name  n  to  correspond  to  the 
value-mode  pair  given  by  v  in  the  current  environment.  Thus  a  call  of 
find  in  this  environment  with  n  as  paraaeter  will  deliver  v.  If 
dec_type  *  1,  then  the  association  is  teaporsry  and  will  disappear  at 
the- end  of  the  current  session.  If  dec_type  *  2  then  the  association 
is  held  in  file-store  and  will  persist  between  sessions.  In  this 
latter  case  the  value  being  nased  aust  be  a  file-store  vslue  and  in  the 
oase  of  a  redefinition  of  an  existing  naae  the  nodes  aust  be  the  sane, 
■o  temporary  name  can  be  defined  if  this  naae  is  already  defined  in  the 
persistent  sense  and  vice-versa.  If  any  of  these  conditions  are  not 
aet,  the  call  of  keep  will  fail  without  ohanglng  the  dictionaries. 

The  keep  procedure  thst  is  bound  to  a  program  is  usually  the  same  as 
that  used  as  a  paraaeter  to  the  current  call  of  the  command  interpreter 
ourt  (see  9.1). 
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8.  Dictionary  utilities 

The  file-store  dictionary  belonging  to  a  user  is  created  at  the  save 
tlaa  as  the  user  is  given  access  to  the  system  by  having  an  envlronaent 
procedure  naaed  in  the  outeraost  environment  (see  9).  Thus  the 
envlronaent  for  casual  non- serious  users  has  an  environment  procedure 
called  play  in  the  outer  envlronaent.  At  the  creation  of  the  dictionary 
it  ms  initialised  to  contain  three  functions  which  are  particular  to 
the  envlronaent.  The  first,  new,  has  already  been  described  (6.1.1)  and 
creates  new  modules  in  this  environment.  The  other  two  are  concerned  1 

with  showing  and  tidying  the  file-store  dictionary.  These  are  given 
names  specific  to  the  user,  using  the  saae  name  as  the  envlronaent 
procedure,  thus  these  procedures  in  the  play  envlronaent  are  called 
show__play  and  tidy_play.  in  what  follows  the  user  naae  is  denoted  by 
User.  | 

8.1  PROC  ahowJUser  *  PAGE: 

This  procedure  will  display  the  file-store  dictionary  of  User  using 
the  editor.  The  PAGE  delivered  by  the  procedure  (by  keying  RESULT)  is 
siaply  the  aaln-store  version  of  an  editable  file  produced  by  editing 
the  display. 

This  display  consists  of  two  initial  lines,  followed  by  a  set  of  line 
triples,  one  for  each  nase  defined  in  the  dictionary.  The  initial 
lines  are  values  of  Curt  aode  Hodule_set  and  01d_dictionary 
respectively.  The  Nodule_set  is  a  pointer  to  the  set  of  aodules 
created  in  this  User  environment.  The  01d_dictlonary  is  a  shaky  disc 
pointer  to  the  contents  of  the  dictionary  before  it  was  last  updated. 

This  value  can  be  used  to  retrieve  old  values  by  using  the  function 
show_old  provided  that  a  disc  garbage  collection  has  not  occurred. 

The- line  triples  following  this  define  each  naae  held  in  the 
dictionary  in  alphabetical  order.  The  first  line  contains  the  naae 
and  the  time  and  date  on  which  it  was  declared  (the  cursor  will  appear 
over  the  aost  reoent  declaration) .  The  second  line  is  the  value 
corresponding  to  this  naae  while  the  third,  if  not  empty,  is  the 
doc  (mentation  file  associated  with  this  value.  Both  of  these  values 
can  be  ao cessed  in  the  normal  edit  sense. 

If  one  wishes  to  delete  nsaes  from  the  dictionary  then  one  deletes 
the  corresponding  line  triples  froa  the  display  and  applies  tldy_User 
to  the  result  of  the  procedure.  _ 


8.2  PROC  tidyJJser  «  (PAGE  p)VOID: 

The  parameter  of  this  procedure  is  intended  to  be  derived  froa 
showJJser  (or  perhaps  froa  some  show_old) .  The  identifiers  and  values 
given  in  the  PAGE  will  become  the  new  dictionary  for  the  User. 


8.3  PROC  show_teap  *  PAGE:  j 

This  procedure  shows  the  temporary  n«es  and  corresponding  values  in  j 
the  saae  way  as  showJJser.  At  the  ssae  time  it  reaoves  all  the  I 
temporary  values  from  "the  local  dictionary;  if  one  wishes  to  retain  J 
thea  (or  some  subset  of  thea)  then  one  uses  tldy_teap.  j 


8.4  PROC  tidy_t«mp  *  (PAGE  p)VOID: 

The  parameter  of  this  procedure  is  intended  to  be  derived  from 
show_tidy  and  gives  a  page  of  identifier-value  correspondences  which 
will  form  the  new  temporary  dictionary  after  the  call. 
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9.  The  User  grocedure 

A  Ump  procedure  accessible  at  the  outeraost  level  of  Fin  («.g.  on* 
accessible  by  am  whoa  •  vdu  is  startsd  up)  consists  of  ths  call  of  an 
anvirooMBt  procadurc  with  a  dictionary  belonging  to  the  user  and  sows 
other  finding  procedures  already  bound  in.  The  dictionary  belongs  to 
the  user  in  the  sense  that  only  he  has  the  procedures  to  find  and  update 
Identifiers  in  it  (he  can  of  course  give  then  to  other  users  if  so 
desired) .One  of  the  other  finding  procedures  is  one  which  looks  for 
identifiers  in  the  cannon  dictionary.  This  includes  nost  of  the  nodules 
and  functions  sectioned  in  this  doewent  and  also  the  function 
ahow_ocnaoa  which  displays  its  contents.  Nornal  users  do  not  have 
access  to  the  keeping  procedure  which  updates  the  connon  dictionary;  in 
fact,  this  is  contained  in  the  priv  dictionary  whose  finding  procedure 
is  bound  into  sons  privileged  Users  in  the  sane  way  as  the  finder  for 
connon  is  bound  into  all  Users 

The  nases  in  a  User's  dictionaries  (both  tenporary  and  persistent)  as 
well  as  all  those  given  by  the  bound  finding  procedures  fora  the  don  a in 
of  the  find  procedure  given  in  7.2.  These  nanes  are  therefore 
accessible  within  progran;  they  are  also  accessible  directly  by  the 
eennand  interpreter,  ourt,  which  is  called  in  each  User  procedure.  In 
fact,  only  those  nanes  are  accessible  in  the  interpretation  of  connands 
and  there  is  no  distinction  between  those  created  by  the  user  and  those 
already  present  in  the  ays ten  (in  connon,  say). 

The  User  procedure  also  naintains  a  nonitpring  file  of  noteable  events; 
these  events  are  usually  where  the  persistent  dictionary  ohanges. 
Entries  are  nade  into  this  file  by  neans  of  the  procedure  nonltor  and  it 
can  be  accessed  by  the  procedure  get_n_file.  Previous  states  of  the 
dictionary  can  be  reinstated  by  using  the  procedure  unwind  on  a 
truncated  version  of  the  nonitoring  file. 

In  the  following  description,  a  typical  User  is  expressed  as  an  Algol68 
procedure;  usually  it  would  not  be  oalled  directly  within  an  Algol68 
progran  but  only  by  the  oonnand  Interpreter  as  part  of  the 
interpretation  of  a  oonnand  line  at  the  outemost  level . 


9.1  PROC  User  a  (VM  par)YM: 

The  Ourt  node  of  User  is  Moded  ->  Hoded 

The  paraneter  per  is  any  value  nods  pair.  The  Curt  node  rules  neans 
that  any  Curt  value  can  be  supplied  as  paraneter  in  a  Curt 
interpretation  of  a  call  of  this  procedure.  This  value  is  declared  to 
have  nane  Op  in  the  initialisation  of  the  tenporary  dictionary  of  the 
eovlronaent.  toother  nme  in  the  Initialisation  is  where  which  is 
used  to  give  an  indication  of  the  context  of  the  environnent  by  the 
contents  of  the  Cbirt  line  eeoh  tine  the  environnent  ohanges  by  inner 
onll  of  tort  (wore  strictly  inner  ceils  of  nake_flnd) . 

The  procedure  Ueer  then  oontinuea  by  searching*- for  a  nne  PASSWORD  in 
the  various  plaoes  available  to  it.  If  it  finds  a  corresponding  value 
then  it  treats  this  as  a  PROC  1010  and  calls  it.  Host  PASSWORDS  are 
erected  and  declared  in  the  user's  dletionary  by  the  procedure, 
password,  which  binds  its  string  peraratcr  to  a  procedure  whloh  asks 
one  to  type  it  out  (invisibly)  on  the  vdu  and  falls  if  it  does  not 
notch  (thus  dsn  failing  the  oall  of  U»«r)  .  Other  nore  oonpl looted 


procedures  could  b«  invented  by  the  user. 

The  procedure  User  then  creetea  all  the  environment  dependant  values 
and  procedurea  (eg  find,  keep,  get_module  etc)  relevant  to  this  user 
and  cal la  the  procedure,  curt.  “ 

PROC  curt  * 

(  PBOC( VECTOR [ ]CHAR )VH  find, 

PROC(IMT, VECTOR [)CHAR,VH)VOID  keep, 

PROC(INT,REF  VECTOR [] CHAR) VOID  monitor, 

VECTOR [] CHAR  first_line)  VM 

This  procedure  interprets  commands  typed  at  the  vdu  and  is  discussed 
in  [23.  The  find  parameter  is  the  procedure  that  the  interpreter  will 
use  to  give  meaning  to  Identifiers  typed  on  the  command  line  and  its 
actual  in  this  call  is  the  find  procedure  of  the  environment. 
Similarly  the  keep  parameter  allows  one  to  do  declarations  of 
identifiers  on  the  command  line  to  update  the  dictionaries  of  the 
environment  by  using  the  keep  procedure  of  the  environment.  The 
first_line  parameter  of  curt  la  the  first  line  that  will  be 
interpreted  and  in  this  call  it  la  the  empty  string  if  the  mode  part 
of  the  par  parameter  of  User  is  Void;  otherwise  it  is  the  string  "Op" . 
The  monitor  parameter  is  called  each  time  a  declaration  is  made  on  the 
Qirt  line  with  its  string  parameter  being  the  Curt  line  Itself  and  its 
integer  parneter  being  1  for  a  temporary  declaration  and  2  otherwise. 
The  actual  used  is  again  generally  available  and  is  described  in  9.2. 

The  answer  delivered  by  User  is  the  answer  delivered  by  the  call  of 
curt. 


9.2  PROC  monitor  *  (I NT  t,  REF  VECTOR UCHAR  mess)VOID: 

If  t  is  not  1,  then  the  line  mess  is  appended  to  the  current 
monitoring  file  followed  by  the  current  state  of  the  user's 
persistent  dictionary;  this  last  appears,  in  a  mendacious  fashion,  as 
an  Int  in  the  file.  The  procedure  monitor  is  called,  for  example,  at 
each  declaration  in  curt,  at  every  amend  module,  at  every  new  module 
and  every  time  a  dictionary  is  tidied;  the  intention  is  to  note  each 
possible  ohange  to  the  dictionary.  Besides  giving  a  record  of  what 
one  has  done,  the  monitoring  file  can  also  be  used  by  the  procedure 
unwind  to  forget  about  undesirable  changes  asde  to  one's  dictionary. 


9.3  PROC  getmjlle  *  ESFXLE: 

The  result  of  a  call  of  this  procedure  is  the  current  stste  of  the 
monitoring  file. 

9.  A  PROC  unwind  ■  (EDFILE  mon)VOID: 

The  parmseter  of  this  procedure  must  be  a  truncated  version  of  the 
current  monitoring  file,  la  the  monitoring  file  at  some  earlier  time 
in  the  session.  This  can  only  be  produced  by  editing  the  result  of  a 
sail  of  get_m_flle  with  the  only  permitted  actions  being  to  delete 
final  pairs  of  lines  (NB  the  lines  are  160  chars  long).  If  this 


condition  is  not  net  the  procedure  will  fail  without  altering  the 
dictionary.  If  it  is  net  then  both  the  dictionary  and  the  current 
nonitoring  file  is  returned  to  what  it  was  at  the  earlier  time  given 
by  the  truncated  nonitoring  file. 
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10.  Conclusion 


This  paper  is  not  Intended  to  be  a  teaching  document  but  rather  a 
description  of  the  basic  building  blocks  of  the  Flex  software.  The 
easiest  way  to  learn  how  to  use  Flex  is  to  use  Flex;  a  good  deal  of 
thoight  and  energy  has  gone  into  the  design  of  a  friendly  user  interface 
and  on-line  teaching  and  information  aids.  The  procedures  described 
here  are  mainly  those  which  are  not  directly  used  by  most  users;  they 
tend  to  be  wrapped  up  in  less  basic  procedures. 

There  many  other  procedures  in  Flex  which  might  have  been  included  in 
this  paper.  Noteable  ommissions  includes  the  listing  and  networking 
procedures.  In  addition,  the  editor  and  the  structure  of  editable  files 
form  such  an  important  part  of  programming  on  Flex  that  it  could  be 
considered  as  part  of  the  System  in  spite  of  the  fact  that  it  does  not 
meet  my  criteria  for  inclusion  given  in  the  Introduction.  However,  as 
each  of  these  topics  merit  a  complete  paper  to  themselves,  the  set  given 
here  probably  forms  a  reasonable  compromise  between  brevity  and 
completeness.  This  set  is  sufficient  to  give  all  the  primitives 
required  for  writing  compilers,  editors,  database  managers,  ...  -  in 
fact,  the  basic  stuff  of  software. 
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11.  Index  Kid  Glossary 

algol68  Algol68  compiler  -  with  CUrt  mode  Edfile->Hoded 

where  Moded  is  either  an  Edfile  (failed  compilation) 
or  a  Compiled  pair ( successful) . 

mentioned  6.1.1 

amend  function  with  Curt  mode  Module  ->  (Compiled pair  ->()) 

used  to  update  program  without  changing  specification, 
mentioned  6.1 

basic_find  finds  set  of  values  associated  with  an  identifier  in 
current  environment*  7.1 

break_sl  soft  interrupt  belonging  to  the  break-in  process,  2.4 


»  c_to_d 

code-block 

common 

current_loader 

curt 

d_to_b 

DATA 

DISCPTR 

DISCREF 

date 

diagnose 

disc-pointer 

disc-reference 

EDFILE 

* 

Exceptions 

failure 


creates  a  code-block  on  disc, 3.2. 3 

that  part  of  a  procedure  which  is  constant, [1 ],3.2.3,6. 

dictionary  containing  values  generally  avaiable  across 
the  system,  mentioned  7.  •  9. 

loader  used  to  load  current  program,  6.2.2 

command  interpreter  used  by  Flex  system, [2]  and  see  9.1 

transforms  a  disc-block  into  corresponding  main-store 
block,  3.3.1 

Algol68  mode  of  object  refered  to  by  a  MODULE, 6.1 
mode  of  a  disc  pointer  ,  HIT  in  Algol68,  3. 
mode  of  a  disc  reference,  DiT  in  Algol68,  3. 
today's  date  ,2.8 

Curt  function  used  to  diagnose  run-time  errors,  see  5. 

held  as  a  pointer  to  a  keyed  block  in  main-store 
held  as  recognisable  bytes  on  file-store,  3.1  etc. 

disc-pointer  which  is  a  disc  variable  containing  one 
word,  3. 1.  3. A. 

Algol68  mode  corresponding  to  Curt  mode  Edfile, 
describing  an  editable  file,  mentioned  8. 

Failures  either  produced  by  software  or  firmware, [1 ],5. 

innaeeesslble  Kernel  procedure  used  to  construct 
diagnostic  ohain  at  exceptions,  see  5. 
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find 


gets  the  value-node  pair  associated  with  an  identifier 
in  current  environment, 7. 2 

fim_dptr  firms  a  ahaky  disc  pointer, 3. 5. 1 

from_disc  reads  the  contents  of  disc  block,  3.3.2 

garbage  collection 

■ain-store  -  implemented  in  the  nicro  code  of  Flex  [1] 
file-store  -  done  off-line  ,  see  3.1 

get_module  delivers  the  interface  values  of  a  nodule, 6. 2.1 

«*t  m_file  delivers  the  current  monitoring  file,  9.3 
””  Curt  node  :  ()  ->  Ed  file 

info  function  to  get  the  information  file  on  an  identifier; 

mentioned  7.1.  Curt  mode  :  Vec  Char  ->  Edfile 

keep  used  to  declare  identifiers  in  current  dictionaries, 7. 3 

LOADER  Algol68  mode  of  loader  ,defined  in  6.2 

nake_flnd  creates  a  new  find  procedure  from  a  basic_find,  7.1,9. 1 

nake_loader  creates  a  loader .described  in  6.2.1 

nake_node  function  to  construct  a  Curt  mode,  mentioned  7.2 

Curt  mode  :  Vec  Char  ->  Mode 

nake_process  oreates  a  new  process, 2. 2 

make__sema  creates  a  new  semaphore, 2. 5 

Moded  Curt  mode  corresponding  to  Algol68  mode  VM;  in  curt 

interpreter,  used  to  transfer  mode  information  into 
and  out  of  procedure  calls;  mentioned  9.1 

MODULE  Algol68  mode  with  corresponding  Curt  mode  Module,  6.1 

Module_set  Curt  mode  for  pointer  to  set  of  modules,  8.1 

monitor  records  a  message  and  state  in  monitoring  file, 9. 2 

new  oreates  a  new  module,  6.1.1 

when  used  as  a  Curt  function  its  mode  is 

Gompiledpair  ->  Module  (see  algol68, amend  etc) 

nawjdr  oreates  a  new  disc  reference, 3. 4. 2 

npb_to_d  write  non-pointer  data  to  disc, 3. 2.1 

01d_dictionary  CUrt  mode  for  shaky  disc  pointer  to  previous  state  of 
dictionary,  see  8.1 


own_ai 

own_time 

p_to_d 

PAGE 

PASSWORD 

password 

pb_to_d 

priv 

shake_dptr 

show_cooBon 

show_old 

show_teap 

ahowJJser 

aoft_int«rrupt 

SPEC 

tidyJUser 

tidy_temp 

tlmed_walt 

to_dr 

unwind 


so'ft_interrupt  for  principal  process, 2. 3 

time  spent  by  current  process  ,2.7 

creates  a  procedure  on  disc, 3* 2. A 

Algol68  node  corresponding  to  Curt  mode  Page  which 
is  a  main store  representation  of  an  editable  file. 
Mentioned  8. 1,8. 2, 8. 3. 8. A 

name  of  password  proc  (Curt  mode  ()->())  in  User 
dictionary,  usually  put  there  by  proc  password,  see  9.1 

function  (Curt  mode  (Vec  Char)->())  which  puts  a 
PASSWORD  into  User  dictionary,  see  9.1 

writes  words  (Including  disc-pointers)  to  disc, 3. 2. 2 

a  dictionary  only  accessible  to  certain  Users,  see  9. 

makes  a  disc  pointer  shaky,  3.5.1 

display  contents  of  common  dictionary,  mentioned  9. 

Curt  mode  :  ()  ->  Page 

display  contents  of  old  state  of  dictionary, 
mentioned  8.1.  Curt  mode  :  01d_dictionary  ->  Page 

display  contents  of  current  temporary  dictionary  ,8.3 
Curt  mode  :  ()  ->  Page 

display  contents  of  User's  persistent  dictionary  ,8.1 
Curt  mode  :  ()  ->  Page 

characterises  a  process,  2.2 

mode  of  disc  ptr  to  "specification"  of  module,  see  6.1 

usually  used  to  delete  names  from  User's  persistent 
dictionary,  8.2  Curt  mode  :  Page  ->  () 

usually  used  to  reinstate  names  in  current  temporary 
dictionary,  8. A  Curt  mode  :  Page  ->  () 

procedure  for  waiting  a  bit, 2.6 

write  to  disc-reference  ,3.A.1 

restore  dictionary  to  earlier  state,  9. A 
Curt  mode  :  Edfile  ->  0 


User 


name  of  a  typical  environment  proo,  aooessed  at  outer 
level,  9*  Curt  mode  :  Moded  ->  Moded 


UVALUE 


Algol68  aode  for  a  value  described  in  7.1 
procedure  for  using  ones  vdu,  A. 


vdu 

Virtual  Machine 

the  Flex  aachine  as  seen  by  a  single  user,  see  2. 

VM  Algol68  aode  giving  a  value-mode  pair  described  in  7.2 
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